WIP Upgrade to rebar3 3.18, with improvements in packaging and release assembly #1097

hmmr · 2021-12-21T02:59:00Z

This is a patchset inspired by the work I have been doing for some months on Riak CS/Stanchion 3.0. It includes:

Upgrade to rebar3 3.17 + a patch fixing a call to git revlist in repos with same-name branch and tag, and eventually, to 3.18 (where that patch has been merged). The bug this patch addresses is triggered when (for example) a build is attempted on dockerhub.com.
Brush up packaging for rpm- and deb-based distros:
- all now include riak.service unit files and require systemd;
- the full list of distros where packaging was verified now includes Centos 7 and 8, Debian 11 and Amazon Linux 2;
- make package now works on OSX 14, where it is essentially the result of make rel, tarred.
Get rid of the - option to su in the launcher script, which removes the su barrier for env vars (something requested in another PR).
Avoid copying leveldb git history when making rel- targets.
Refactoring of the release assembly:
- make make rel relocatable again (specifically, to enable OSX package);
- make riak-admin command equivalent to riak admin command (also applies to riak-repl and riak-debug);
- point cuttlefish and rebar3_cuttlefish to TI-Tokyo repos, with support for fqdn type and bin_script template synchronized with that in relx-4.5.0.

There are no changes in Erlang code.

Testing was done as follows:

on each of the OSes covered, Riak package is built natively, with make package, and installed;
Riak CS and Stanchion packages are built and installed, just as above;
riak pid, riak ping, riak-admin status work as expected;
riak-admin test passes;
riak-admin member-status and other cluster-related commands work;
riak-debug succeeds;
riak-cs-admin test succeeds;
Riak can be built with this Dockerfile and run as part of Riak CS suite in Riak CS Docker Bundle.

works better for non-standard installations of otp

See TI-Tokyo/rebar3@48344c200353c It comes with a new relx which allows for many simplifications in the launcher script: * The riak script it generates has rpc facility built in. * No need to supply dummy sys.config and vm.args. We do, however, need to write and delete the pid file ourselves.

Specifically, those in eleveldb submodules # Conflicts: # Makefile

* set DEBEMAIL; * move deb/debian/vars.config to ..; * add missing build dependency on libpam0g-dev; * rm /var/lib/riak on purge.

* add gcc-c++ to BuildRequires; * embrace systemd.

Incidentally, bump riak_kv dep to 3.0.9.2 (does code:load in schema, just for osx)

The `-` option is there primarily for one side effect: it does`cd` to riak user's HOME (/var/lib/riak). Critically, this dir has the erlang cookie file, which is read from the new node started as part of some riak-admin commands (e.g., riak-admin test). It, however, creates a barrier for env vars, which is undesirable. If we cd manually into riak's HOME before the call to `su`, the piggy node now can find the cookie in its cwd, and execution of the command succeeds.

* resuscitate riak-chkconfig; * make `make rel` relocatable again, fix riak-debug for it; * remove runner_* substitution vars in all rel/**/vars.config;

martincox · 2022-01-18T11:02:25Z

rel/files/riak


+case "$1" in


Why does each command need to be present in this case - is this not already handled in the extended start script as extensions?

It's an effort to make hyphenated and non-hyphenated forms equivalent.

I don't think it works as expected, and I'm not even sure that resurrecting the hyphenated commands is warranted - what purpose does it serve? It's been a couple of years since we moved to start script extensions. You now have to re-insert a bunch of boilerplate environment stuff at the top of the script files to make them work, whereas that was all inherited with from the root start script with extensions.

My opinion is that it's a backwards step, unless there's a compelling reason that I'm not aware of / considering.

The tidy up across the rest of the release config is very decent though, and much needed. Some of the deps currently reference TI forks, which would need to target basho, but guess that would be fixed up before everything gets merged in.

To deal with the easier part first: re-pinning deps to TI-Tokyo repos has a single purpose: pull in cuttlefish and rebar3_cuttlefish, not so much for the fqdn data type in cuttlefish but rather for several commits in the plugin that make it compatible with rebar3 3.18 (by ioolkos, see this one and thereabout), synchronize its internal install_update_escript with the "upstream" version of it in relx, and last but not least, this little gem.

I note that the fqdn-type patch has already been merged in basho/cuttlefish, but there is no tag. If you do the tagging, I will then prepare the necessary PRs to bump cuttlefish version where necessary (it is an explicit dependency in bitcask, clique, eleveldb and riak_sysmon), and collect a patchset for another PR in rebar3_cuttlefish.

Regarding the phasing out of hyphenated forms, I have no strong opinions and will gladly follow the party line (although I would invite @Bob-The-Marauder to this discussion, who has been in the business of dealing with customers for some time).

For the record, my understanding of the underlying machinery is as follows:

The riak script generated by relx and/or cuttlefish provides basic commands like start, stop, console, pid, ping, rpc. It is how riak is started/stopped in riak_test setting. It is not under our control.

The other riak, the one created from the template in rel/files, has a distinct and specific purpose:

it takes care of the pid file (relx-generated one will not do this for us);

it does su as appropriate, and is therefore installed in PATH when riak is installed from a package;

it launches riak-admin etc when called as riak admin.

I saw this last item precisely as a way to enable non-hyphenated forms (if we remove riak-admin and its hyphenated friends from PATH, the move to hide hyphenated forms will be complete, from the user standpoint). Apparently, by "move to start script extensions" you mean to do it differently -- perhaps by injecting code in the script produced by relx? If so, I would be happy to rework my contribution accordingly, but I didn't see how relx can be massaged to achieve that.

hmmr · 2022-03-27T18:32:27Z

@martincox Re:

If it is absolutely necessary to bridge the gap of hyphenated forms being deprecated, why not take a less invasive route and create proxy scripts for the hyphenated forms that live in /usr/sbin/ with something in the form of:

With 1ce0262, when installed from a package on a debian11 system, we now have:

root@debian:~# riak admin
Usage: riak-admin { cluster | join | leave | backup | restore | test | 
                    reip | erl-reload | wait-for-service | 
...
root@debian:~# riak-admin
The hyphenated form of this command is deprecated. Please fix your scripts to call `riak admin` instead.

Usage: riak-admin { cluster | join | leave | backup | restore | test | 
                    reip | erl-reload | wait-for-service | 
                    ringready | transfers | force-remove | down |

With regards to the PID writing - does that not work? It should be handled as part of the start script. I mean, I've just checked over a few clusters (3.*) and all have PIDs in the expected directory.

It's another possible regression. I have the extended_start_script_hooks stanza in relx/deb section in rebar.config, unchanged since 3.0.9, but if I delete this line, the pid file is not written. riak pid still works (pid is obtained by calling os:getpid/0, so no wonder). I will investigate.

martinsumner · 2022-03-29T12:10:25Z

@hmmr wanted to try test this today, but had issues fetching the referred to tag in riak_repl. Is the TI-Tokyo riak_repl repo public?

hmmr · 2022-03-29T13:06:41Z

@martinsumner It is indeed private. The change I pushed in TI-Tokyo repo is just s|git://|https://| on top of tag riak_kv-3.0.9. I guess you can do this change manually in the official repo, tag it riak_kv-3.0.10, and I will then re-point riak_repl to the new tag accordingly in this PR.

I have traced the pid file regression, which was in rebar3_cuttlefish plugin (it was introduced by vernemq people in their more recent changes, and adopted by too eager me). I have reverted to version 0.2.0, tweaking it to work with rebar3.18 (and noticed that @martincox has already done the same). I have just re-pointed rebar3_cuttlefish to basho/develop branch, and it is great again.

There are still issues with f75df62, which I am trying to fix, but you should be able to build it locally with make rel.

…zens of deps

…ut, for faster package builds

…built)

…upgrade-to-rebar3.17

# Conflicts: # rebar.config

hmmr · 2022-05-02T20:20:49Z

Superseded by #1108.

Andrei Zavada added 2 commits December 14, 2021 18:14

nonexistent target ballclean

5ddfd28

determine otp version from erlang:system_info(otp_release)

4ec03f3

works better for non-standard installations of otp

hmmr force-pushed the hmmr/develop-3.0/upgrade-to-rebar3.17 branch 4 times, most recently from 99fd82c to 8207626 Compare December 28, 2021 20:49

hmmr force-pushed the hmmr/develop-3.0/upgrade-to-rebar3.17 branch 4 times, most recently from 409d079 to 7cff235 Compare December 29, 2021 20:34

Andrei Zavada and others added 9 commits December 30, 2021 00:33

upgrade rebar3_cuttlefish (to a version that supports fqdn data type)

73f12e9

avoid copying .git dirs when preparing rel- targets

3db7582

Specifically, those in eleveldb submodules # Conflicts: # Makefile

improvements in deb packaging (compliance with current standards, etc)

6976d5e

* set DEBEMAIL; * move deb/debian/vars.config to ..; * add missing build dependency on libpam0g-dev; * rm /var/lib/riak on purge.

clean up after dropping yokozuna

b5951f8

improvements in rpm packaging

10598c5

* add gcc-c++ to BuildRequires; * embrace systemd.

enable packaging for Amazon Linux 2

d83d0ae

osx package

cb67886

Incidentally, bump riak_kv dep to 3.0.9.2 (does code:load in schema, just for osx)

hmmr force-pushed the hmmr/develop-3.0/upgrade-to-rebar3.17 branch from 86ad602 to 7e3661a Compare December 29, 2021 22:40

Andrei Zavada added 2 commits January 2, 2022 21:01

refactor and repair release assembly

8b95c99

* resuscitate riak-chkconfig; * make `make rel` relocatable again, fix riak-debug for it; * remove runner_* substitution vars in all rel/**/vars.config;

upgrade rebar3 to 3.18

9cb62b8

hmmr force-pushed the hmmr/develop-3.0/upgrade-to-rebar3.17 branch from 7e3661a to 9cb62b8 Compare January 2, 2022 19:02

hmmr changed the title ~~WIP upgrade to rebar3.17~~ Upgrade to rebar3 3.18, with improvements in packaging and release assembly Jan 5, 2022

martinsumner requested a review from martincox January 12, 2022 20:25

martincox reviewed Jan 27, 2022

View reviewed changes

hmmr changed the title ~~Upgrade to rebar3 3.18, with improvements in packaging and release assembly~~ WIP Upgrade to rebar3 3.18, with improvements in packaging and release assembly Jan 29, 2022

Andrei Zavada added 3 commits February 5, 2022 00:46

rm node_package relic

88c76ff

alpine packaging groundwork

9f25dab

launcher without su, just for alpine

b052781

Andrei Zavada added 6 commits March 29, 2022 03:09

pid file for local release is useless

937e08d

change to rebar3_cuttlefish-0.2.1 (0.2.0 with rebar3.18 API fix)

c74a556

riak_not_running is actually a template

3628c74

let relx handle pid files (unbroken in rebar3_cuttlefish-0.2.1)

5c0009e

rm leftover debian/riak.init

58b063a

rebar3.org recommends starting riak with 'foreground'

f75df62

tmp point rebar3_cuttlefish to a branch

a50898f

Andrei Zavada added 12 commits March 30, 2022 21:36

missing items in debian/control BuildDepends

4a3f0ff

debian/Makefile: don't do make clean when nothing has been built yet

3140383

deb/Makefile: link _build/default/{libs,plugins} to avoid fetching do…

de4b6e9

…zens of deps

export RUNNER_LOG_DIR to unbreak cuttlefish-generated scripts

36d6970

move hooks into own dir under rel/files

a6b196a

why prepend riak- to PKG_ID?

b03a592

symlnk deps from _build/default/lib/* into tree snapshot in rel/pkg/o…

f776cd7

…ut, for faster package builds

try explicit config/vm.args, to unbreak relx internode ops

8647c98

amend de4b6e9 to only symlink libs (cuttlefish plugin fails unless re…

323453d

…built)

Merge branch 'hmmr/develop-3.0/fbsdng-support' into hmmr/develop-3.0/…

231d6f1

…upgrade-to-rebar3.17

point deps to develop-3.0 branches

2afabb2

tmp remove rebar.lock while deps are floated

f0dc94c

hmmr force-pushed the hmmr/develop-3.0/upgrade-to-rebar3.17 branch from 6274458 to f0dc94c Compare April 2, 2022 19:21

Andrei Zavada and others added 3 commits April 4, 2022 18:46

typo in rebar.config

332f71f

with rebar3_cuttlefish unbroken, undo hyphenated command routing

e0b92c3

# Conflicts: # rebar.config

make use of cf_config in riak-chkconfig, again

57314bd

hmmr mentioned this pull request May 2, 2022

Packaging improvements & upgrade to rebar3.18 #1108

Closed

hmmr closed this May 2, 2022

hmmr deleted the hmmr/develop-3.0/upgrade-to-rebar3.17 branch May 3, 2022 18:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP Upgrade to rebar3 3.18, with improvements in packaging and release assembly #1097

WIP Upgrade to rebar3 3.18, with improvements in packaging and release assembly #1097

hmmr commented Dec 21, 2021 •

edited

Loading

martincox Jan 18, 2022

hmmr Jan 27, 2022

martincox Jan 28, 2022

hmmr Jan 29, 2022

hmmr commented Mar 27, 2022

martinsumner commented Mar 29, 2022

hmmr commented Mar 29, 2022

hmmr commented May 2, 2022

WIP Upgrade to rebar3 3.18, with improvements in packaging and release assembly #1097

WIP Upgrade to rebar3 3.18, with improvements in packaging and release assembly #1097

Conversation

hmmr commented Dec 21, 2021 • edited Loading

martincox Jan 18, 2022

Choose a reason for hiding this comment

hmmr Jan 27, 2022

Choose a reason for hiding this comment

martincox Jan 28, 2022

Choose a reason for hiding this comment

hmmr Jan 29, 2022

Choose a reason for hiding this comment

hmmr commented Mar 27, 2022

martinsumner commented Mar 29, 2022

hmmr commented Mar 29, 2022

hmmr commented May 2, 2022

hmmr commented Dec 21, 2021 •

edited

Loading